June 1, 1994 



Research 
Report 



125 



Prudent Engineering Practice 
for Cryptographic Protocols 



Martin Abadi and Roger Needham 



3D3DDSD 

Systems Research Center 

130 Lytton Avenue 

Palo Alto, California 94301 



Systems Research Center 



The charter of SRC is to advance both the state of knowledge and the state 
of the art in computer systems. From our establishment in 1984, we have 
performed basic and applied research to support Digital's business objec- 
tives. Our current work includes exploring distributed personal computing 
on multiple platforms, networking, programming technology, system mod- 
elling and management techniques, and selected applications. 

Our strategy is to test the technical and practical value of our ideas by 
building hardware and software prototypes and using them as daily tools. 
Interesting systems are too complex to be evaluated solely in the abstract; 
extended use allows us to investigate their properties in depth. This ex- 
perience is useful in the short term in refining our designs, and invaluable 
in the long term in advancing our knowledge. Most of the major advances 
in information systems have come through this strategy, including personal 
computing, distributed systems, and the Internet. 

We also perform complementary work of a more mathematical flavor. Some 
of it is in established fields of theoretical computer science, such as the 
analysis of algorithms, computational geometry, and logics of programming. 
Other work explores new ground motivated by problems that arise in our 
systems research. 

We have a strong commitment to communicating our results; exposing and 
testing our ideas in the research and development communities leads to im- 
proved understanding. Our research report series supplements publication 
in professional journals and conferences. We seek users for our prototype 
systems among those with whom we have common interests, and we encour- 
age collaboration with university researchers. 



Robert W. Taylor, Director 



Prudent Engineering Practice 
for Cryptographic Protocols 

Martin Abadi and Roger Needham 
June 1, 1994 



Roger Needham is at the University of Cambridge Computer Laboratory, 
Pembroke Street, Cambridge CB2 3QG, UK. 



A preliminary version of this paper has appeared in the Proceedings of 
the 1994 IEEE Computer Society Symposium on Research in Security and 
Privacy. 



©Digital Equipment Corporation 1994 

This work may not be copied or reproduced in whole or in part for any com- 
mercial purpose. Permission to copy in whole or in part without payment 
of fee is granted for nonprofit educational and research purposes provided 
that all such whole or partial copies include the following: a notice that 
such copying is by permission of the Systems Research Center of Digital 
Equipment Corporation in Palo Alto, California; an acknowledgment of the 
authors and individual contributors to the work; and all applicable portions 
of the copyright notice. Copying, reproducing, or republishing for any other 
purpose shall require a license with payment of fee to the Systems Research 
Center. All rights reserved. 



Authors' Abstract 

We present principles for designing cryptographic protocols. The principles 
are neither necessary nor sufficient for correctness. They are however helpful, 
in that adherence to them would have prevented a number of published 
errors. 

Our principles are informal guidelines; they complement formal methods, 
but do not assume them. In order to demonstrate the actual applicability of 
these guidelines, we discuss some instructive examples from the literature. 
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1 Introduction 



Cryptographic protocols, as used in distributed systems for authentication 
and related purposes, are prone to design errors of every kind. Over time, 
various formalisms have been proposed for investigating and analyzing proto- 
cols to see whether they contain blunders. (Liebl's bibliography [11] includes 
references to protocols and formalisms.) Although sometimes useful, these 
formalisms do not of themselves suggest design rules; they are not directly 
beneficial in preventing trouble. 

We present principles for the design of cryptographic protocols. The 
principles are not necessary for correctness, nor are they sufficient. They are 
however helpful, in that adherence to them would have simplified protocols, 
and prevented a number of published confusions and mistakes. 

We arrived at our principles by noticing some common features among 
protocols that are difficult to analyze. If these features are avoided, it be- 
comes less necessary to resort to formal tools — and also easier to do so if 
there is good reason to. The principles themselves are informal guidelines, 
and useful independently of any logic. 

We illustrate the principles with examples. In order to demonstrate 
the actual applicability of our guidelines, we draw these examples from the 
literature. Some of the oddities and errors that we analyze have been docu- 
mented previously (in particular, in [4]). Other examples are new: protocols 
by Denning and Sacco [6], Lu and Sundareshan [12], Varadharajan, Allen, 
and Black [29], and Woo and Lam [32]. We believe they are all instructive. 

Generally, we pick examples from the authentication literature, but the 
principles are applicable elsewhere, for example to electronic-cash protocols 
(e.g., [15]). We focus on traditional cryptography, and on protocols of the 
sort commonly implemented with the DES [18] and the RSA [26] algorithms. 
In particular, we do not consider the subtleties of interactive schemes for sig- 
natures (e.g, [7]). Moreover, we do not discuss the choice of cryptographic 
mechanisms with adequate protection properties, the correct implementa- 
tion of cryptographic primitives, or their appropriate use; these subjects are 
discussed elsewhere (e.g., [30, 17]). 

Throughout, we concentrate on the simple principles with the largest 
potential applicability and payoff. Admittedly, the literature is full of inge- 
nious protocols and attacks. We do not attempt to formulate the laws that 
underly this ingenuity, and perhaps it is not necessary to do so. We hope 
that our simple principles and examples will contribute to the engineering 
of robust cryptographic protocols. 
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2 Basics 



A protocol, for present purposes, is a set of rules or conventions defining an 
exchange of messages between a set of two or more partners. These part- 
ners are users, processes, or machines, which we will generically refer to as 
principals. In a cryptographic protocol the whole or part of some or all of 
the messages is encrypted. We interpret the term encryption fairly broadly, 
applying it for example to signature operations. For present purposes, en- 
cryption and decryption are defined as key-dependent transformations of a 
message which may be inverted only by using a definite key; the keys used 
for encryption and decryption are the same or different, depending on the 
cryptographic algorithm used. 

We find two basic, overarching principles for the design of secure crypto- 
graphic protocols. One principle is concerned with the content of a message 
and the other with the circumstances in which it will be acted upon: 

1. Every message should say what it means — its interpretation should 
depend only on its content. 

2. The conditions for a message to be acted upon should be clearly set 
out so that someone reviewing a design may see whether they are 
acceptable or not. 

Next we explain these principles. They lead to other, more specific recom- 
mendations, which we discuss in the subsequent sections. 

2.1 Explicit communication 

In full, our first basic principle is: 
Principle 1 

Every message should say what it means: the interpretation of 
the message should depend only on its content. It should be pos- 
sible to write down a straightforward English sentence describ- 
ing the content — though if there is a suitable formalism available 
that is good too. 

For example, an authentication server S might send a message whose 
meaning may be expressed thus: "After receiving bit-pattern P, S sends 
to A a session key K intended to be good for conversation with B" . All 
elements of this meaning should be explicitly represented in the message, so 
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that a recipient can recover the meaning without any context. In particular, 
if any of P, S, A, B, or K are left to be inferred from context, it may be 
possible for one message to be used deceitfully in place of another. 

This principle is not completely original. In [4], we recommend the 
use of a logical notation in generating and describing protocols — essentially 
proposing a method to follow the principle. Establishing the correspon- 
dence between the logical protocol and its concrete implementation can be 
a simple matter of parsing, as for example in [31, Section 4.3.2]. Although 
a precise comparison of informal ideas is difficult, we also find an affinity 
with Boyd and Mao's proposal that protocols should be robust in the sense 
that "authentication of any message in the protocol depends only on infor- 
mation contained in the message itself or already in the possession of the 
recipient" [3]. An operational variant on this theme appears in the work of 
Woo and Lam, who say that a protocol is a full information protocol if "its 
initiator and responder always include in their outgoing encrypted messages 
all the information they have gathered" [33]. 

2.2 Appropriate action 

For a message to be acted upon, it does not suffice that the message be 
understood; a variety of other conditions have to hold too. These conditions 
often consist of what may be regarded informally as statements of trust, 
though this anthropomorphic notion should be used with care. 

Statements of trust cannot be wrong though they may be considered 
inappropriate. For example, if someone believes that choosing session keys 
should be done by a suitably trusted server rather than by one of the par- 
ticipants in a session, then he will not wish to use a protocol such as the 
Wide-mouthed-frog protocol [4]. 

In general, we have: 
Principle 2 

The conditions for a message to be acted upon should be clearly 
set out so that someone reviewing a design may see whether they 
are acceptable or not. 

2.3 Secrecy 

The secrecy of certain pieces of information is essential to the functioning 
of cryptographic protocols. Obviously, a protocol should not publicize the 
cryptographic keys used for communicating sensitive data. Further, it is 
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important to know how long a piece of information needs to remain secret, 
and to protect it accordingly. 

None of our principles makes these points explicitly. Rather, all of our 
principles warn against mistakes that often imply the loss of secrecy, in- 
tegrity, and authenticity. Some of the examples clarify how the principles 
relate to the need for secrecy. 

There may be more to say about secrecy guidelines for cryptographic 
protocols, but these are outside the scope of the present paper. 

2.4 Examples and other principles 

Below we discuss many concrete examples where errors would have been 
avoided by using our two basic principles. We also introduce other principles, 
some of them corollaries of the basic ones. In particular, we recommend: 

• Be clear on how encryption is used, and on the meaning of encryption. 

• Be clear on how the timeliness of messages is proved, and on the 
meaning of temporal information in messages. 

Hopefully, the two basic principles will encourage a certain lucidity in the 
design of cryptographic protocols, and thereby make it easier to follow the 
other principles. 

3 Notation 

We adopt notation common in the literature. That notation is not quite 
uniform and, in the examples, we make compromises between uniformity of 
this paper and faithfulness to the original notation. 

In this paper, the symbols A and B often represent arbitrary principals, 
S represents a server, T a timestamp, N a nonce (a quantity generated for 
the purpose of being recent), K a key, and K~ l its inverse. In symmetric 
cryptosystems such as DES, K and K~ l are always equal. For asymmetric 
cryptosystems such as RSA, we assume for simplicity that the inversion 
operation is an involution (so K~ l equals K); we tend to use K~ l for 
the secret part and K for the public part of a key pair (K, K~ l ). We write 
{X}k to represent X encrypted under K; anyone who knows {X}k and 
the inverse of K can obtain X . If K is secret, we may refer to {X}k as a 
signed message, and to the encryption operation as a signature. 
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For example, 

Message 4 B -+ A : {T a + l} Kab 

describes the fourth message in a protocol; in this message, B sends to A 
the timestamp T a incremented by 1, under the key K a f,. In this example, 
the subscript a in T a is a hint that A first generated T a ^ the subscript cib 
in K a i, is a hint that K a f, is intended for communication between A and B. 
Similarly, we may write K a for A's public key. 

The typical notation "Message 4 B — > A : X" needs to be interpreted 
with some care. The messages constituting a cryptographic protocol are not 
sent in a benign environment (in which they would frequently be unneces- 
sary) but in one with error, corruption, loss, and delay. Accordingly we may 
read "Message 4 B — > A : X" only as "the protocol designer intended X 
to be originated by B as the fourth message in the protocol, and for it to 
be received by A v . There is nothing in the environment to guarantee that 
messages are made in numerical order by the principals indicated, received 
in numerical order or at all by the principals indicated, or received solely by 
the principals indicated. If assurance is needed about any of these matters 
it must be provided as part of the function of the protocol. 

4 Naming 

The most immediate instance of Principle 1 prescribes being explicit about 
the names of principals: 

Principle 3 

If the identity of a principal is essential to the meaning of a 
message, it is prudent to mention the principal's name explicitly 
in the message. 

The names relevant for a message can sometimes be deduced from other 
data and from what encryption keys have been applied. However, when 
this information cannot be deduced, its omission is a blunder with serious 
consequences. 

The principle is obvious and simple, yet it is commonly ignored. We give 
several examples of fairly different natures. 

Example 3.1 In [6, p. 535], Denning and Sacco propose a protocol for key 
exchange based on an asymmetric cryptosystem. In the first two messages 
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of this protocol, A obtains certificates CA and CB that connect A and B 
with their public keys K a and Kf,, respectively. The exact form of CA and 
CB is not important for our purposes. The interesting part of the protocol 
is Message 3. There, A sends to B a key K a i for subsequent encrypted 
communication between A and B, with a timestamp T a . The protocol is: 

Message 1 A -> S : A, B 

Message 2 S -> A : CA, CB 

Message 3 A ^ B : CA, CB, {{K ab , T a } K -i} Kb 

This third message is encrypted for both secrecy and authenticity. When 
A sends this message to B, it is important that no other principal obtain 
K a b; the use of Kf, provides this guarantee. Furthermore, the intent is that, 
when B receives the message, B should know that A sent it (because of the 
signature with K~ l ). Finally, B should know that the message was intended 
for B (because of the use of Kb). 

Unfortunately nothing provides this final guarantee, with dramatic con- 
sequences. Any principal B with which A opens communication can pretend 
to a third party C that it actually is A, for the duration of validity of the 
timestamp. For simplicity, we omit the exchanges which yield the public 
certificates CA, CB, and CC When A opens communication with B, 

Message 3 A -+ B : CA, CB, {{K ah , T a } K -i} Kb 

B removes the outer encryption, re-encrypts with K c , sends: 

Message 3' B -+ C : CA, CC, {{K ah , T a } K -i} Kc 

and C will believe that the message is from A. In particular, C might send 
sensitive information under K a b, and B may see it when perhaps only A 
should. 

The intended meaning of Message 3 is roughly "At time T a , A says that 
K a i, is a good key for communication between A and B" . Any adequate 
format for Message 3 should contain all of these elements expressly or by 
implication. The obvious one is: 

Message 3 A ^ B : CA, CB, {{A, B, K ah , T a } K -i} Kb 

although the name A might be deducible from K~ l . It is important that 
this format must not be used for anything else; we return to this point in 
Section 7. □ 



6 



Example 3.2 In [32, pp. 42-43], Woo and Lam present an authentication 
protocol based on symmetric-key cryptography. When B wants to check 
that it is in A's presence, it runs: 



Message 1 A — > B 

Message 2 B -> A 

Message 3 A -> B 

Message 4 B -> S 

Message 5 S — > B 



A 

{N b }l<as 

{A, {N b } Kas } Kbs 
{Nb}K bt 



Here Nf, is a nonce, S is a server, and K as and Ji'^ are keys that A and 
_B share with S. Basically, A claims his identity (Message 1); B provides 
a nonce challenge (Message 2); A returns this challenge encrypted under 
K as (Message 3); B passes this message on to S for verification, bound with 
A's name under Kf, s (Message 4); S decrypts using A's key and re-encrypts 
under _B's (Message 5). If S replies {Nb}K b ,, then B should be convinced 
that A has responded to the challenge Nf,. 

The protocol is flawed. The connection between the messages is not 
sufficient. In particular, nothing connects _B's query to S with S"s reply. 
The protocol is therefore vulnerable to an attack, as follows. Suppose that 
B is willing to talk to A and to C roughly at the same time; A may be 
off-line. Then C can impersonate A: 



Messa^ 


;e 


f 


C - 


■> B 




Messa^ 


;e 


f 


c - 


■> B 


C 


Messa^ 


;e 


2 


B - 


■¥ A 




Messa^ 


;e 


2' 


B - 


■¥ C 


^' 


Messa^ 


;e 


3 


C - 


■> B 




Messa^ 


;e 


3' 


c - 


■> 5 


{Nb} Kc . 


Messa^ 


;e 


4 


B - 


-> 5 


{N b } Kcs } Kbs 


Messa^ 


;e 


4' 


B - 


-> S 


{C, {N b } Kcs }i< bs 


Messa^ 


;e 


5 


S - 


> 5 


iW'}K b . 


Messa^ 


;e 


5' 


s - 


> 5 


{N b }K bs 



where N" is the result of decrypting {Ni,}k cs using K as . In Messages f 
and f, C tells _B that both A and C want to establish a connection. In 
Messages 2 and 2', B replies with two challenges; C receives one normally, 
and captures the other one, which was destined to A's address. In Messages 
3 and 3', C replies to both challenges. On A's behalf, it can send anything. 
On its own behalf, C responds to the challenge intended for A. In Messages 4 
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and 4', B consults S about the two responses. Messages 5 and 5' are the 
replies from S. One of these replies matches nothing, while the other one 
contains the challenge intended for A. On the basis of these replies, then, 
B must believe that A is present. 

The existence of this attack demonstrates that the messages in the proto- 
col are not sufficiently explicit about the identity of the principals in ques- 
tion. (After we contacted them, Woo and Lam came to the same con- 
clusion [33].) Reasoning as in Example 3.1, we may remove the flaw, by 
changing the last message of the protocol to 

Message 5 S -> B : {A, N b } Kbs 

A further change is discussed in Example 6.2. □ 

Example 3.3 A more dramatic example is provided by the basic Internet 
protocol of Lu and Sundareshan [12, pp. 1016-1017]. This protocol is rather 
complicated for a detailed description. Its intent is to allow two principals 
A and B to obtain a session key, with the mediation of local servers and 
gateways. 

On the other hand, the fundamental flaw of the protocol is rather simple. 
One immediately sees that neither A nor B ever receives a message that 
contains the other's name. Obviously, this opens the door for confusions 
between different connections. It also allows some easy attacks to defeat the 
protocol. After we contacted them, the authors published a correction [13], 
where names appear in messages explicitly. □ 

5 Encryption 

The next group of principles and examples concern encryption. They are 
generally related to Principle 1, since they concern what encryption means 
and what it does not mean. 

5.1 The uses of encryption 

As the examples below illustrate, encryption is used for a variety of purposes 
in the present context [19]. 

• Encryption is sometimes used for the preservation of confidentiality. 
In such cases it is assumed that only intended recipients know the key 
needed to recover a message. When a principal knows K~ l and sees 
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{X}k, it may deduce that X was intended for a principal who knows 
K~ l ] and it may even deduce that X was intended for itself, given 
additional information. 

• Encryption is sometimes used to guarantee authenticity. In such cases 
it is assumed that only the proper sender knows the key used to encrypt 
a message. The encryption clearly contributes to the overall meaning 
of the message. The extreme situation is that where a principal shows 
that a key is known by encrypting a null message or a timestamp. 

• While encryption guarantees confidentiality and authenticity, it also 
serves in binding together the parts of a message: receiving {X, Y}k is 
not always the same as receiving {X}k and {Y}^. When encryption 
is used only to bind parts of a message, signature is sufficient. The 
meaning attached to this binding is rather protocol-dependent, and 
often subtle. 

• Finally, encryption can serve in producing random numbers. There 
is a vast theory that explains the relation between one-way functions 
and random-number generators. At the level of abstraction that we 
consider, one typically assumes that random numbers are available 
without examining how they are constructed (but see Example 7.1). 

There is considerable confusion about the uses and meanings of encryp- 
tion. If the cryptography is asymmetric it may be obvious what is intended; 
if the cryptography is symmetric, it is generally not. 

Principle 4 

Be clear about why encryption is being done. Encryption is not 
wholly cheap, and not asking precisely why it is being done can 
lead to redundancy. Encryption is not synonymous with security, 
and its improper use can lead to errors. 

Example 4.1 The Kerberos protocol [16] is based on the original Needham- 
Schroeder protocol [20], but makes use of timestamps as nonces in order 
to remove flaws demonstrated by Denning and Sacco [6] and in order to 
reduce the total number of messages required. Like the Needham-Schroeder 
protocol on which it is based, the Kerberos protocol relies on symmetric- key 
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cryptography. A slightly simplified version of the protocol goes: 



Message 1 A -> S 

Message 2 S -> A 

Message 3 A -> B 

Message 4 B -> A 



A, 5 

{Ta + l}A- ob 



ab 



Here, T s and T a are timestamps, and L is a lifetime. Initially the server S 
shares the keys K as and Kf, s with the principals A and B; after execution, 
A and B share K a f,. This protocol serves to illustrate different uses of 
encryption; we describe the protocol step by step: 

• Encryption is not essential for Message 1. Without encryption, though, 
an attacker can flood S with requests for keys, by falsifying instances 
of Message 1. It is common for designers not to focus on this sort of 
vulnerability. 

• Message 2 requires encryption: K a f, should remain confidential, and S 
should sign the message as a proof of authenticity. 

• We may however question why double encryption is used in Mes- 
sage 2. Most probably, this use of double encryption is simply in- 
herited from the Needham-Schroeder protocol (see Example 9.1). As 
in the Needham-Schroeder protocol, double encryption does not add 
anything from the points of view of confidentiality or authenticity, and 
it is not entirely free of cost. 

It does provide a guarantee: when B receives the first part of Mes- 
sage 3, it knows that A must have extracted it from Message 2, and 
hence that A must have looked at Message 2. (Heintze and Tygar [9] 
discuss a similar use of encryption in a variant of the Otway-Rees pro- 
tocol [23].) This interpretation of encryption is sound, but slightly 
unusual, and probably not what the protocol designers had in mind. 

• In the second part of Message 3, encryption is used for an entirely 
different purpose: A encrypts T a with K a f, in order to prove knowledge 
of K a i, near time T a . 

In general, T a may be a few hours newer than T s . However, if T a is not 
much different from T s , the encryption is redundant: the use of double 
encryption in Message 2 gives adequate proof of knowledge of K a f,. In 
this case, the second part of Message 3 could be omitted altogether, 
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and B could use T s in Message 4. (Were we to propose a change in 
Kerberos, however, it would not be removing an encryption in Mes- 
sage 3 but rather eliminating the double encryption in Message 2, 
which would become {T s , L, K ab , B} Kas , {T s , L, K ab , A} I<bs .) 

• The encryption in Message 4 serves an analogous purpose. 

□ 

Examples 6.1 and 6.2, below, illustrate the interaction of encryption 
and nonces. In short, encryption is often used for binding when a nonce 
provides an association between a message and an implicit name. Following 
Principle 3, we make this missing name explicit. The use of both encryption 
and nonces is then much simpler and economical. 

5.2 Signing encrypted data 

Signature is used, as the name suggests, to indicate which principal last 
encrypted a message. It is frequently taken as also guaranteeing that the 
signing principal knew the message content. It is hard, but fortunately 
unnecessary to be precise about what knowing is. An informal notion is 
sufficient for stating the next principle: 

Principle 5 

When a principal signs material that has already been encrypted, 
it should not be inferred that the principal knows the content of 
the message. On the other hand, it is proper to infer that the 
principal that signs a message and then encrypts it for privacy 
knows the content of the message. 

Failure to follow this principle can lead to errors, as in the next example. 

Example 5.1 The CCITT X.509 standard contains a set of three protocols 
using between one and three messages [5]. The protocols are intended for 
signed, secure communication between two principals, assuming that each 
knows the public key of the other. 

The CCITT proposal has problems. We discuss one problem described 
in [4]; it appears already in the one-message protocol: 

Message 1 A ^ B : A, {T a , N a , B, X a , {Y a } Kb } K -i 

Here, T a is a timestamps, N a is a nonce (not used), and X a and Y a are user 
data. The X.509 protocol actually uses hashing to reduce the amount of 
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encryption. We do not show this because it does not affect our argument 
about X.509. 

The protocol is intended to ensure the integrity of X a and Y a , assuring 
the recipient of their origin, and to guarantee the privacy ofY a . However, 
although Y a is transferred in a signed message, there is no evidence to suggest 
that the sender is actually aware of the data sent in the private part of the 
message. This corresponds to a scenario where some third party intercepts 
a message and removes the existing signature while adding his own, blindly 
copying the encrypted section within the signed message. This problem can 
be avoided by several means, the simplest of which is to sign the secret data 
before it is encrypted for privacy. □ 

A particular case of the principle concerns hash functions: 

Example 5.2 It is common to use hash functions in order to save on encryp- 
tion with asymmetric-key systems (see for example [25, 10]). In particular, 
A can send a signed, confidential message to B as follows: 

Message 1 A -> B : {X} I<bl {H(X)} K -i 

where if is a one-way hash function. When A sends this message, only B 
discovers X , and B knows that A signed the hash of X . For example, if 
X is a request for an operation, B may then infer that A supports X . We 
should think of one-way hashing as encryption, and then Principle 5 applies. 
In this instance, it means that B cannot be certain that A knew X. For 
example, if X is a secret such as a password, B cannot be certain that A 
knew the secret; A may have received H(X) from a friend. □ 

In general, we recommend careful examination of those protocols that 
require a principal to sign material that is both already encrypted and such 
that the principal cannot decrypt it. On the other hand, signing before 
encrypting is not a bill of health; see Example 3.1. 

6 Timeliness 

An important part of the meaning of a message is made up of temporal 
information. Further, one common precondition for acting upon a message 
is that there is reason to believe that the message is fresh, and hence not a 
replay of an old one. This freshness has to be inferred from some compo- 
nent of the message. Whatever this talisman, it should be bound together 
with the rest of the message so that it cannot be attached to a message 
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being replayed. It is important to understand properly how the freshness 
component works, and what is being assumed about it. 

The next group of principles and examples concern time. They all ad- 
dress what must be assumed about proofs of timeliness, and what they 
actually prove. 

6.1 Timestamps, sequence numbers, and other nonces 

When guarding against replay of messages from an earlier run of the same 
protocol it is common to use nonces as part of a challenge-response exchange. 
A message is sent which leads to a reply which could only have been produced 
in knowledge of the first message. The objective is to guarantee that the 
second message is made after the first was sent, and sometimes to bind 
the two together. There is sometimes confusion about nonces — are they 
guaranteed new, random, unpredictable? Whence we propose: 

Principle 6 

Be clear what properties you are assuming about nonces. What 
may do for ensuring temporal succession may not do for ensuring 
association — and perhaps association is best established by other 
means. 

Example 6.1 In [23], Otway and Rees describe the following protocol. It 
allows two parties A and B to establish a shared key K ab , with the help of 
a server S with whom they share keys K as and K bs , respectively, using the 
nonces M, N a , and TV;,: 

Message 1 A -> B : M, A, B, {N ai M, A, B} Kas 

Message 2 B S : M, A, B, {N a , M, A, B} Ka ], {N b , M, A, B} I<bs 

Message 3 S B : M, {N ai K ab } Kat , {N bl K ab ) Kbt 

Message 4 B A : M, {N ai K ab } Kat 

This is the first protocol analyzed in [4]. Perhaps because of our relative 
inexperience, we were rather bold in the idealization of this protocol — in 
assigning meanings to these messages. As a consequence, we suggested in 
passing that the encryption of N b in Message 2 is unnecessary. As Mao 
and Boyd have since explained in detail [14], the encryption of N a and N b 
is essential: because N a and N b are bound with the names A and B by 
encryption in Messages 1 and 2, they can serve as secure references to A 
and B in Messages 3 and 4. Encryption is being used not for secrecy, but 
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for binding; nonces are exploited not only as proofs of timeliness but also as 
substitutes for names. 

Much encryption can be avoided when names are included in S"s reply: 



Message 1 A — > B 

Message 2 B -> S 

Message 3 S -> B 

Message 4 B -> A 



A, B, N a 
A, B, N a , N b 

{N ai A, l>>. K ah } Ka „ {N bl A, l>>. K ab ] Kb 
{N a , A, B, Kab} Kas 



The protocol is not only more efficient but also conceptually simpler after 
this modification. □ 

Example 6.2 Example 3.2 describes a protocol due to Woo and Lam. Look- 
ing back at the use of encryption in that protocol, we notice that the purpose 
of encryption in Message 4 is to bind two parts of a message. Looking back 
at the use of nonces, we notice that N b provides only a proof of freshness, 
but not an association to the name A as was intended. 

As we argue in Example 3.2, Message 5 should mention the name A 
explicitly for the sake of security. With that change, the binding of Message 4 
becomes unnecessary. Further, TV;, needs to be viewed only as a proof of 
freshness. The protocol is now simply: 



It is not essential for nonces to be unpredictable. In fact, the value of a 
counter makes a proper nonce. However, predictable nonces should be used 
with caution: 

Principle 7 

The use of a predictable quantity (such as the value of a counter) 
can serve in guaranteeing newness, through a challenge-response 
exchange. But if a predictable quantity is to be effective, it 
should be protected so that an intruder cannot simulate a chal- 
lenge and later replay a response. 

Example 7.1 Protocols that rely on synchronized clocks must be accompa- 
nied by protocols to access time servers. These protocols cannot themselves 



Message 1 A — > B 

Message 2 B -> A 

Message 3 A -> B 

Message 4 B -> S 

Message 5 S —> B 



A 

{N b }l<as 

A, B, {N b } K 
{A, N b } Kbs 



□ 
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rely on synchronized clocks, but they can rely either on random nonces or 
on predictable nonces. 

Using random nonces, we may have: 

Message 1 A -> S : A, N a 
Message 2 S -> A : {T s , N a } Kat 

where T s is the current time and N a is a random nonce, used as a challenge. 
After this exchange, A accepts T s as the current time if the response arrived 
reasonably soon after the challenge. Reiter exploits random nonces roughly 
in this manner [24]. 

This protocol would not work if N a were predictable. An attacker C 
could make A set its clock back: early on, C makes a request for the current 
time using a future value of the nonce, saves S"s response, and then forwards 
the response to A when A uses this value in a challenge. 

When N a is predictable, it should be protected: 

Message 1 A -> S : A, {N a } Kas 
Message 2 S -+ A : {T S1 {N a } Kat } Kat 

The attack is no longer possible. Note that it is not important for N a 
to remain secret (and after all we have assumed it is predictable). The 
encryption in Message 1 serves to construct a quantity {N a }x as that only 
A and S can predict from a quantity that anyone can predict. 

A similar exchange arises in the context of Kerberos. Neuman and 
Stubblebine suggest using Kerberos itself to obtain the time from a time 
server [22]. The quantity used as a nonce is roughly predictable: it is an 
incorrect timestamp; since it is encrypted, we expect no difficulties. □ 

Freshness can also be proved by the use of timestamps. Timestamps are 
appealing because they seem easier to use than random numbers. However, 
their use is not always correct. There are a number of aspects of prudent 
practice in the use of timestamps, and they are often misunderstood. One 
use of timestamps is as a kind of nonce. In this case the ultimate user of 
the timestamp, as part of a response, is the same as the originator of the 
challenge of which the timestamp was part. This style of use does not depend 
on clock synchronization at all, but does need care because the timestamp 
may be to a large extent predictable. Another style of use does depend on 
clock synchronization. The recipient of a message looks at a timestamp in 
it, and accepts the message only if the timestamp is within a reasonable 
interval of the recipient's local time. In this case we have: 
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Principle 8 

If timestamps are used as freshness guarantees by reference to 
absolute time, then the difference between local clocks at various 
machines must be much less than the allowable age of a message 
deemed to be valid. Furthermore, the time maintenance mecha- 
nism everywhere becomes part of the trusted computing base. 

Example 8.1 Timestamps have received abundant attention in the authen- 
tication literature. Gong, in particular, has described problems arising from 
the use of incorrect timestamps [8]. Therefore, we keep this example brief, 
summarizing Gong's example for the Kerberos system. 

In Kerberos, as elsewhere, a principal with a slow clock is exposed to 
all sorts of difficulties, since the principal may mistake expired certificates 
for current ones. It is more interesting that a fast clock can also be an 
opportunity for attackers. If a principal A signs a request at time To using a 
timestamp T, with To < T, an attacker C can replay this request near time 
T. The effect of the request at time T may benefit C, for example if C is 
using A's workstation at time T. 

Bellovin and Merritt have discussed further problems in the use of times- 
tamps in Kerberos [2]. □ 

6.2 What is fresh: use vs. generation 

Roughly, a bit-pattern is fresh if any message that contains it must be recent. 
Clearly, it does not suffice that the bit-pattern participate in one recent 
message, if it may also participate in old ones. This observation is most 
important for keys: 
Principle 9 

A key may have been used recently, for example to encrypt a 
nonce, yet be quite old, and possibly compromised. Recent use 
does not make the key look any better than it would otherwise. 

Example 9.1 The Needham-Schroeder protocol and the Kerberos protocol 
are similar in structure and in goal; the Needham-Schroeder protocol reads: 



Message 1 A -> S 

Message 2 S -> A 

Message 3 A -> B 

Message 4 B -> A 

Message 5 A — > B 



A, B, N a 

{N a , B, K ab , {K ab , A} Kbs } Kas 
{K ab , A} Kb , 

{Nb + l} Kab 
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As in Kerberos, only A makes contact with S, who provides A with the 
session key, K a b, and a certificate encrypted with _B's key K bs conveying 
the session key to B. Then B decrypts this certificate and carries out a 
nonce handshake with A to be assured that A is present currently, since the 
certificate might have been a replay. As explained in Section 7, Message 5 
contains N b + 1 rather than N b in order to distinguish this message from 
Message 4. 

Messages 4 and 5 of the Needham-Schroeder protocol were intended to 
convince B that A is present and active. They do not (and in fact were 
not intended to) convince B that K ab is fresh, and it was pointed out by 
Denning and Sacco that compromise of a session key could allow an intruder 
to deceive B [6]. Once the importance of freshness of K ab is recognized, a 
solution may be found by using timestamps, as suggested by Denning and 
Sacco. In another solution, described in [21], B sends a nonce to S, and 
then S includes it in its certificate. □ 

Example 9.2 In [29], Varadharajan, Allen, and Black present several pro- 
tocols for delegation in distributed systems. We take as an example the 
one for delegation in a Kerberos environment [29, p. 273]. In this protocol, 
client B shares the key K bi with the authentication server; B has generated 
a timestamp T& and wants a key K bs to communicate with another server S. 
The authentication server gives K bs and {K bs }K bt to S. Then S constructs 
{T;, + l}x b ,j an d sends: 

Message 5 S B : S, B, {T b + l} I<bsl {K bs }i< bt 

The authors reason: 

Having obtained Kf, s , B is able to verify using T& that S has 
replied to a fresh message, so that the session key is indeed fresh. 

However, B obtains no proof that K bs is fresh. All that B can deduce is that 
Kb s has been used recently — but it may be an old, compromised key. □ 

7 Recognizing messages and encodings 

It seems important that principals recognize messages for what they are, 
and can associate them correctly with the current step of whatever protocol 
they are executing. There are two possible forms of confusion (which could 
happen together): first, between the current message and a message of sim- 
ilar purpose from a previous run of the protocol, and second, between the 
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current message and a message belonging either elsewhere in the protocol, 
or to another protocol. Snekkenes [27] and Syverson [28] have constructed 
examples of protocols where these confusions can arise. 

We believe that these confusions are less important when all our princi- 
ples are correctly followed. If a message says what it means then we have 
no reason to be concerned with its context. The message is meaningful (or 
meaningless) on its own, whether we know that it belongs in a particular 
protocol instance or not. 

Still, mapping a message to the appropriate protocol instance is con- 
venient when it contributes to the compact encoding of the message. For 
example, Message 1 of the Wide-mouthed-frog protocol always means some- 
thing of the form: "the signer (with key K as ) says at time T a that K ab is 
a good key to talk to B v (see Example 11.2). If the principal who receives 
a message can be certain that it is Message 1 of this protocol, then the 
message can be encoded compactly: {T a , B, K a f ) }K as . 

We arrive at the following recommendation: 

Principle 10 

If an encoding is used to present the meaning of a message, then 
it should be possible to tell which encoding is being used. In 
the common case where the encoding is protocol dependent, it 
should be possible to deduce that the message belongs to this 
protocol, and in fact to a particular run of the protocol, and to 
know its number in the protocol. 

Mapping a message to the appropriate protocol instance is often trivial 
if the message obeys our other principles. If the message contains sufficient 
timeliness guarantees and sufficient names, then the current instance cannot 
be confused with an old instance, or an instance for other principals. It could 
be confused with a concurrent instance for the same principals. 

Next we give an example where this principle is relevant, but where other 
more important principles apply as well. 

Example 10.1 If signature or confidentiality are mediated by symmetric- 
key encryption, then a particular form of confusion is associated with the 
direction in which a message is intended to pass. 

In the Needham-Schroeder protocol, a participant sends a challenge Nf, 
and receives Nf, + 1 as a response (see Example 9.1): 

Message 4 B -+ A : {N b } Kab 
Message 5 A B : {N b + l} Kab 
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The purpose of incrementing Nf, is to distinguish the challenge from the 
response. Without this increment, an attacker could send _B's message back 
to B, who could mistake it for A's reply. The purpose of incrementing 
a nonce has often been misunderstood. For example, a operation 
appears in Kerberos, where it is unnecessary. 

The messages would be clearer if they were rewritten: 

Message 4 B -> A : {N-S Message 4: N b } I<ab 
Message 5 A -> B : {N-S Message 5: N b } Kab 

though in fact any way of making the two messages different will do. (This 
is an instance of our suggestion to Syverson mentioned in [28].) 

Guided by the principle that messages should say what they mean, how- 
ever, we ought to rewrite the messages: 

Message 4 B — > A : {B says that K ab is a good key to talk to A, 

sometime after receiving K a b}K ab , -/V& 

Message 5 A — > B : {A says that K ab is a good key to talk to B, 

sometime after receiving Nf,}K ab 

Of course, shorter encodings of these meanings can be constructed. Not 
only is there no risk of confusion between these two messages, but also each 
of them is self-contained. It is not important to know that they are part of 
a particular instance of the Needham-Schroeder exchange. □ 

8 Trust 

The use of timestamps makes explicit for the first time a question of trust. 
When can a principal A rely on another principal B putting a correct times- 
tamp in a message? The answer usually given is that this is acceptable if A 
trusts B in relation to timestamps. 

The idea of trust is pervasive and a little elusive. A careful classification 
of types of trust is given in [34] and is taken further by Klein in her doctoral 
thesis. There are questions both of practice and philosophy to do with trust 
relations — for example whether they are transitive or not — which it would 
not be appropriate to pursue here. We may simply say that A trusts B in 
regard to some function if a loss of security to A could follow from B not 
behaving in the specified way; it is usually difficult or impossible for A to 
verify _B's good behavior. 
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There is some measure of trust involved whenever one principal acts on 
the content of a message from another. It is essential that this trust be 
properly understood. 

Principle 11 

The protocol designer should know which trust relations his pro- 
tocol depends on, and why the dependence is necessary. The 
reasons for particular trust relations being acceptable should be 
explicit though they will be founded on judgment and policy 
rather than on logic. 

Example 11.1 Complete loss of security could follow from a Kerberos server 
issuing wrong timestamps. The server, and its source of time, must be 
trusted by all concerned. This, it may be pointed out, is a case in which 
clients can to some extent monitor the good behavior of the trusted server 
because the correct time is public and global. If a client reads GPS time 
it will have reason for suspicion if Kerberos' time varies from this time 
significantly. □ 

Example 11.2 The Wide-mouthed-frog protocol uses symmetric- key cryp- 
tography and an authentication server. It transfers a key from A to B via 
S in only two messages: 

Message 1 A -+ S : A, {T a , B, K ab } Kat 
Message 2 S -+ B : {T s , A, K ab } Kbt 

First, A sends a session key K ab to S, including a timestamp T a . Then S 
checks T a and forwards the message to B, together with its own timestamp 
T s . Finally, B checks T s and accepts the session key K ab for communication 
with A. Thus, A is trusted to choose a session key. This kind of trust is often 
thought unacceptable because of the quality requirements placed on key 
generation such as secrecy, non-repetition, unpredictability, and doubtless 
more. □ 

Example 11.3 Principals associate public keys with other principals by 
consulting public-key certificates. These certificates can be issued by certifi- 
cation authorities (CAs). CAs are trusted to certify a key only after proper 
steps have been taken to identify the principal that owns it. Since there is 
no global source of authority, it is not surprising that this is an area where 
questions of transitivity of trust come up. It may happen that the only way 
A can find out _B's public key is by accepting a certificate from CA\ for 
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CAi 's public key which is used to sign a certificate for CA3 's public key . . . 
which is used to sign a certificate for _B's public key, for example. In this 
case A knows and trusts CA\ but has never heard of the other certification 
authorities — and maybe even distrusts them. □ 

Example 11.4 It is usually taken for granted that the two principals in 
an authentication dialogue are honestly working to the common end of es- 
tablishing a secure communication channel for subsequent use. This is not 
always the case, as may be seen in communication between potential ene- 
mies or between security forces and terrorists. Possible sorts of bad behavior 
are disclosure of keys and forgery of messages. Therefore, if this assumption 
is made in a particular case then it should be explicit. □ 

Example 11.5 An access control list (ACL) is a statement of trust [1]: if 
principal A appears on the ACL for an operation then A is trusted when 
it says that the operation should be performed (that is, when it makes a 
request). It can be a complex matter to determine whether the statement of 
trust that the ACL represents is appropriate. Often, the question of whether 
it is appropriate makes little sense, particularly in the context of completely 
discretionary access control policies. Nonetheless, understanding ACL's and 
their consequences is essential to security. □ 

In practice, it is not very common for complicated inferences about trust 
to be necessary. With the exception of the chains of trust of Example 11.3, 
which are likely to be simpler in practice than they might be in theory, 
it is usually not difficult to isolate the trust relations being relied on in a 
particular circumstance. It is valuable to do so explicitly, because this may 
lead to useful debate about the appropriateness of these trust relations. 

9 Conclusion 

We have found the principles and examples described in this paper useful 
in our own work. Perhaps it is because of this that they bear a certain 
subjective character. We do however believe that they respond to an im- 
mediate general need, in a discipline where some basic mistakes appear in 
print several times. 

Many of our suggestions can be embodied in development methods and 
in formalisms. While these are helpful, we tried to emphasize an informal 
understanding of some issues essential for security. We hope that our guide- 
lines will help improve the practice of designing cryptographic protocols. 
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